-
-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Projections generated code may fail compilation due to order of switch case statements #2751
Projections generated code may fail compilation due to order of switch case statements #2751
Conversation
…e (will only fail sometimes)
…odegen and implements extensive sorting tests Disclaimer: Comparer implementation may not work properly if interface types are used in projections. Current implementation relies on using entire type hierarchy for sorting, starting from base type, within same hierarchy level type name sort is used.
…g logic in `EventTypePatternMatchFrame` Adds support for having event types as interfaces of that is ever a valid scenario. Adjust tests in accordance to functional changes.
The implementation was updated from prior version for simplicity and better encapsulation. |
I'm working on this one now |
And #sadtrombone, this change breaks a bunch of tests. I'm investigating now. |
@svrx Just for your later reference, the usage of |
@jeremydmiller you're right, apologies for overlooking that fact. In this case this PR is doing nothing. |
After upgrade to version 6 some issue have been identified with compilation of generated code.
When a projection depends on events from different levels of the same inheritance chain, the sorting of methods performed during code generation has been found to be non-deterministic.
Example:
Will sometimes throw a
Unreachable code detected
error during compilation of generated code, due to havingBaseEvent
appearing in switch case order before any of the derived events.Further investigation has shown that root cause of the issue may reside in
EventTypeComparer
implementation.At first glance it looks fine, although the resolution of comparison isn't granular enough, hence when being processed for sorting through .Net internals (depending on API flavour used, may be a QuickSort or Heap+Introspective sort), and optimizations are applied in regards divide and conquer nature of algorithms, having assumptions taken based on partitions and equality (as per result of comparer), which in turn results in some entries never being compared, since all the items in the partition being processed having been reported to be equal by the comparer (comparer returns 0).
Relates to #2749.